Зачастую клиенты обращаются к разработчикам как к волшебникам, с надеждой, что те создадут чудо-IT-продукт. Он решит все проблемы: приведёт толпы клиентов, увеличит продажи, снизит издержки. Вот только без усилий самого заказчика и без точных экономических расчётов это невозможно.
Оценивают ли заказчики экономический эффект от внедрения каждой фичи? Ставят ли разработчикам только те задачи, которые 100 % приведут к результату? Практика показывает, что планирование со стороны заказчика, конечно, есть, но бэклог задач, поставленных перед разработчиками, редко соотносится с целями и задачами бизнеса и ещё реже пересматривается. А ведь после месяцев разработки без понимания экономического эффекта легко прийти к отрицательным результатам и выйти за границы бюджетов.
Другая проблема — конфликты интересов отделов и департаментов. Чтобы команда работала эффективно и проект достигал целей быстрее, часть задач в бэклоге должна иметь высший приоритет, а часть — более низкий. Если у разных отделов (на стороне заказчика) нет понимания, что их задачи отодвигаются в угоду другим задачам справедливо, порождается большое количество домыслов и конфликтов.
Как именно подойти к вопросу планирования управления разработкой с учётом перечисленных проблем, рассмотрим в этой статье.
Движение маленькими шагами и цикл Деминга
Эдвард Деминг сформулировал модель непрерывного управления качеством PDCA: plan–do–check–act (рус. планирование – действие – проверка – корректировка). Цикл PDCA тесно связан с философией Agile и так же призывает нас действовать короткими итерациями, находиться в тесной связи с реальностью и каждый раз проверять, идём ли мы в нужную сторону.
Чтобы разработка продукта была эффективной, необходимо:
1. чётко сформулировать цель, наметить план (plan);
2. совершить нужные действия в соответствии с планом и целями (do);
3. при каждом обороте колеса (каждом цикле разработки) регулярно проверять, в правильном ли направлении мы движемся (check);
4. если наши действия не приближают нас к цели, скорректировать их в нужную сторону (act).
Похоже на принципы разработки MVP, правда?
В одной из предыдущих статей мы уже обсуждали, что по Agile программное обеспечение — это запутанные системы с большим количеством факторов, причинно-следственные связи между которыми неясны. При заказе разработки любому заказчику сложно предвидеть все проблемы, с которыми столкнутся программисты, и сформулировать требования к готовому продукту.
Но есть эффективные способы, которые помогут добавить ясности и упорядочить работу. Давайте подробно рассмотрим методику Impact Mapping и юнит-калькулятор как один из прикладных инструментов DDDM (принятие решений на основе данных, англ. data-driven decision making).
Impact Mapping
Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса. Для этого нужно построить интеллект-карту с ответами на четыре главных вопроса.
1. Why? Зачем нужен этот продукт? Какую задачу бизнеса он должен решить?
2. Who? Кто может влиять на достижение этой цели?
3. How? Что он может сделать?
4. What? Какие конкретные шаги должен сделать ответственный в рамках своих задач?
Пример работы метода Impact Mapping
Типичные проблемы в управлении разработкой, от которых спасает Impact Mapping
1. Излишний функционал
C Impact Mapping на виду ценность каждого действия. Если ценности нет, значит, это избыточное решение — нужно от него отказаться.
2. Несогласованность действий, отсутствие контроля и координации внутри компании-заказчика
Для ответа на вопрос «who?» нужно определить всех, кто влияет на решение проблемы. Руководители производственного отдела и отдела продаж, маркетологи и логисты, любые другие сотрудники, которые могут влиять на продукт разработки и итоговое достижение целей, должны как минимум встретиться и обсудить все задачи.
Зона ответственности каждого будет записана в карту влияния (англ. impact map). Это упрощает контроль над выполнением решений.
Что бывает, если пропустить этот шаг, рассказываем в следующем кейсе.
Мы делали B2B-портал для оптового поставщика продуктов питания. Заказчик описал нужный ему функционал, но оказалось, что в реальной жизни всё работает не так, как в его мечтах. Узнать об этом удалось только при тестировании продукта одним из департаментов, который никто не посчитал нужным привлечь к созданию технического задания (отдельный вопрос, зачем им вообще понадобилось техническое задание). Запуск проекта пришлось отодвинуть.
3. Трудно сравнивать варианты выбора
Для каждой цели в Impact Mapping группируются все возможные варианты достижения этой цели. После проведения анализа и сравнения их эффективности на конкретных KPI/OKR можем быть уверены в правильности своего решения (и никаких мук выбора).
4. Сложно планировать время и бюджет на разработку
Пожалуй, это самый распространённый страх заказчиков перед гибкими методологиями в разработке. Но когда все действия разбиты на шаги, планировать гораздо легче, правда? Если выполнять работы короткими итерациями (например в две недели), соблюдать цикл PDCA, регулярно сверять свои действия с целями, быстро вносить корректировки при отклонениях — согласитесь, будет легче добиться успеха, чем при горизонте планирования в год или пятилетку.
Главное последствие использования карт влияния — чёткое решение бизнес-задач заказчика, а не функционал ради функционала.
Пример Impact Mapping для интернет-магазина одежды и обуви
Допустим, в IT-компанию приходит заказчик — владелец крупного интернет-магазина одежды и обуви с запросом на срочный редизайн сайта.
Проектные менеджеры не могут взять задачу с такой формулировкой, потому что это не соответствует data-driven подходу в принятии управленческих решений. Сначала нужно задать вопрос «зачем?» и определить цель проекта, затем оцифровать её, записать в числовом выражении. Иначе будет невозможно оценить результаты и сделать выводы («мы молодцы, достигли цели» или «мы не смогли достичь цели, давайте думать, почему и как это исправить»).
Например, после совместного обсуждения может выясниться, что бизнес-цель заказчика — рост продаж на 1,5 % в ближайшие три месяца.
Проектным менеджерам необходимо сделать Impact Mapping вместе с заказчиком, и картина может получиться такой: добиться увеличения продаж на 1,5 % можно четырьмя способами.
Метод Impact Mapping можно применять и для B2B-порталов, например оценивать процент использования портала при заказах (в идеале — 100 %). Для CRM/BPM-системы целевым показателем может быть процент пользователей, работающих в CRM, от общего количества сотрудников.
В случае с нашим заказчиком, который хотел редизайн, возникает вопрос: возможно, редизайн ему вовсе не нужен? Чтобы это узнать, сравним все варианты решения и выберем самый выгодный. Полезный метод для такого сравнения — юнит-экономика. Он также помогает проверить, как ваши ценности соотносятся с реальными действиями.
Рассмотрим более подробно полезнейший инструмент: юнит-калькулятор, который мы сами всегда используем для e-Commerce-проектов и рекомендуем использовать всем до того, как приступить к задаче на разработку.
Юнит-калькулятор
Каждое действие (разработка каждого кусочка функционала) в идеале должно быть связано с какой-то ценностью проекта. Зелёная кнопка или новый дизайн — всё должно как-то изменить метрики проекта и как-то окупиться. Ведь если разработка не связана с ценностью для бизнеса, затраты на разработку будут казаться заказчику очень высокими.
Юнит-экономика наглядно показывает рентабельность каждого изменения в проекте или проекта целиком: сколько зарабатывает (или теряет) бизнес с каждого заказа, с каждого пользователя, каждого конечного покупателя. Для этого удобно использовать юнит-калькулятор в виде Excel-таблицы. Давайте рассмотрим самый упрощённый вариант такого калькулятора (на самом деле в юнит-экономике гораздо больше влияющих факторов и гораздо более сложные формулы, но на этом примере мы сможем уловить главные принципы расчёта).
Пример простого юнит-калькулятора
В этой таблице мы меняем значения во влияющих ячейках (поток пользователей или потенциальных клиентов, конверсия, число платящих, доход на одного платящего, сколько в среднем платит клиент, издержки на каждой продаже или комиссия, число покупок на одного платящего), чтобы увидеть изменение значений в зависимой ячейке (gross profit, или доход).
В качестве влияющих ячеек можно добавлять любые факторы вашего конкретного бизнеса. Например, разные каналы продаж, стоимость привлечения новых пользователей, изменение затрат на логистику и т. д.
В некоторых случаях, получая задачи от клиентов, мы предлагаем им сначала воспользоваться юнит-калькулятором и оценить, какое влияние окажет внедрение новой фичи и как изменится доход.
Зачем нам это?
Не можем позволить себе работу «в стол»; дефицит квалифицированных разработчиков и требование рынка постоянно что-то улучшать приводят к тому, что бэклог проекта всегда больше, чем может сделать команда в реальности. Фичи, которые хочет внедрить клиент, нужно сортировать по приоритетам, а от некоторых и вовсе отказываться.
Свежий пример
Cейчас мы работаем над e-Commerce-проектом для крупного ювелирного бренда. Оплата заказов в их интернет-магазине ведётся на сайте банка. Клиент хочет переделать чекаут и сделать форму оплаты прямо на сайте.
Чтобы взять эту задачу в работу, проектному менеджеру нужно соотнести её ценность с конечными бизнес-целями проекта. Основной проблемой может стать отсутствие аналитики. Что делать, если никто никогда не отслеживал, какой процент потенциальных покупателей «отваливается» на шаге оплаты? Действительно ли оплата через сайт банка плохо влияет на продажи? Если разница в конверсии нулевая или незначительная, то выгоды от изменения формы оплаты не будет, зато в это время мы не сможем сделать какой-то другой, более значимый функционал. Эффект же может быть вообще противоположным: покупатели будут опасаться платить сразу на сайте, что снизит продажи. Без аналитики состояния «до» невозможно понять, хуже или лучше станет «после».
В этом примере сначала нужно подключить web-аналитику, чтобы собрать данные для обоснованного решения. Если увидим, что проблема действительно есть, будем менять форму оплаты по циклу PDCA: спланировали – изменили – измерили – если результат не удовлетворил, откатили назад.
Что делать после оценки и сравнения всех способов достижения цели?
1. Если у фичи, предлагаемой клиентом, нет значимой роли,
наличие этих сведений может помочь клиенту изменить приоритеты бэклога.
2. Если юнит-калькулятор показывает, что изменение конверсии даже на 0,01 % даст значимый финансовый результат,
начинать улучшения стоит с самых узких мест воронки продаж. Но далеко не всегда конверсия — главный фактор. Иногда лучше сначала поработать с retention (удержанием) или обеспечить проект качественным трафиком, и только после этого возвращаться к разработке фич.
Вывод
При заказе разработки клиенты обычно воодушевлены. Им кажется, что теперь-то найдётся та самая волшебная таблетка, которая решит их проблемы. Они фокусируются на IT, забывая о конверсии и рентабельности.
После работы с ФРИИ (Фондом развития интернет-инициатив) мы твёрдо усвоили, что составлять Impact Mapping и считать юнит-экономику каждого проекта необходимо до старта работ. И потом при внедрении любых новшеств постоянно их пересматривать и пересчитывать.
В идеале это должен делать заказчик. Но бывает, мы видим, что решения касательно разработки принимаются без учёта конкретных цифр, и в таких случаях готовы помочь консультацией.
Так мы развиваем у наших заказчиков data-driven подход к принятию управленческих решений, и результаты этой работы нас радуют: bad features сведены к нулю, бизнес-цели клиентов достигаются быстро, что выражается в том числе в высоком NPS по нашим проектам (за последние два месяца команда дважды получала максимальные 10 баллов).
